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The  Data  Reorganization  Forum 
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•  Broad  community  participation  includes: 

-  FFRDCs  and  Government/Defense  Laboratories 

-  Defense  integrators 

-  Commercial  embedded  multicomputer  vendors 

-  Commercial  HPC  tool  vendors 

•  Examining  API’s,  algorithms,  and  application  requirements 


Join  the  mailing  list  discussion! 

Goal:  Final  specification  by  June  2001 


What  Problems  Does 
Data  Reorg  Try  To  Solve? 


Data  Partitioning  and  Redistribution  Issues  for 
Signal/Image  Processing  (SIP)  Applications 


•  Block  partitioning  is  most  common 

-  Whoie  probiems  stored  in  1  memory  for  performance 

•  Data  redistribution  communication  is  “severe” 

-  Prototypicai  exampie  is  matrix  transpose  in  2DFFT/SAR 


Azimuth 


Interface  Scalability 
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Long-term  future:  higher-level  /  integrated  /  00  ??? 
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Future  Practice  (with  Data  Reorg  API) 

•  Programmer  uses  high-level  partitioning  services 

•  Middleware  handles  data  partitioning  details 

•  Data  redistribution  with  a  single  high-level  call 

•  Compute  using  VSIPL 


Easier  to  scale 
programming 
effort 


State  of  the  Art  (current  standard  APIs) 

•  Programmer  manually  computes  data  partitioning 

•  Programmer  manually  redistributes  data  (MPI  or  MPI/RT) 

•  Compute  using  VSIPL 


Hard  to  scale 
programming 
effort 
to  large 
systems 


Data  Reorg  Interface  Example 


Example:  Data  movement  with  block  to  cyclic  redistribution 


This  example  shows  a  one-dimensional  data  set 
stored  in  block  fashion  mapped  on  three  nodes  being 
re-distributed  in  cyciic  fashion  over  two  nodes. 


Application  programmer  uses  DRI  to  move  data 
DRI  hides  complex  data  movement  from  programmer 


Increasing  Processing  Capability 
(|jP  generations) 


Model-Year  Portability 


Portable  software  leverages 
inevitable  advances  in  COTS  HPC 
technology 

Defense  system  lifetimes:  long 
COTS  HPC  system  lifetimes:  short 


“Point”  solutions  specific  to  a 
single  vendor  are  long-term 
cost  ineffective 


Portable  software  with  high 
performance  is  a  powerful 
tool  and  is  the  ultimate  goal 


(latency,  throughput,  bisection  bandwidth, ...) 
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Vendor  A  product  line 
Vendor  B  product  line 


\  Processor  support  limited 
/  or  dropped  in  later  products 


+ 
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Increasing  Network  Performance 


Challenges  to  Achieving 
Consensus  In  A  Committee 

Context 


Three  Areas  of  Concern 


Data  Reorg 
Committee  Status 


Data  Reorg 

Objects  and  Implementation  Approaches 


•  Uniquely  part  of  Data  Reorganization  API 

•  Must  be  provided  in  all  Data  Reorg  implementations 

•  Objects: 

-  DRI_Global_Data 

-  DRI_Partition 

-  DRI_Distribution 

-  DRI_Layout 

-  DRI_View 

-  DRI_Overlap 


Data  Reorg 

Objects  and  Implementation  Approaches 


DRI  “CORE” 


Middleware  Adapter 

*  Defines  a  hybrid  interface  that  ieverages  supporting  middleware 

-MPI 

-  MPI/RT 

-  Mercury  PAS 

-  Sky  SCL 

•  Objects: 

-  Selected  from  “Standalone”,  depending  on  supporting  middleware 


Data  Re-org  Forum  Plan 


•  Two  more  official  meetings 

•  Several  informal  “working”  meetings 

-  Resolve  issues  with  buffers  and  buffersets 

-  Resolve  issues  with  memory  layouts  and  distributions 

•  Near-Term  activities: 

-  Establish  CORE  and  Standalone  Interfaces 

-  Define  MPI  Middleware  Adapter  for  Data  Reorg 

-  Final  document  detailing  ideas  and  lessons  learned 


In  the  long  term,  the  forum  feels  that  a  larger  effort  in 
this  area  would  have  substantial  benefits  for  the  high- 
performance  embedded  computing  community 

MITRE 


